GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 4 –AAA, POST#8)- 2/11/2011

I’m back !!!!! On the study horse that is...

AAA – What is it ?

“Triple A”, as it is sometimes called, is a model for access control. It really is the model and basic frame work for security. There are 3 distinctive features in AAA, which are:

Authentication

Authorization

Accounting

Authentication

Authentication is the process to determine whether someone or something (entity) is, in fact, who they say they are.  This is commonly done with user credentials (logon and password). The credentials are then presented to a “server” for verification. Other means, such as tokens and digital certificates can also be used in place of or combined with user credentials. This is called multi layer authentication. It is used to enhance the authentication process.

Authentication uses UDP port 1812, prior to IANA allocation 1645

Authorization

Once the entity is authenticated. Authorization can then take place. Authorization is the process of granting access or permissions to the entity. You are allowing the entity the privilege to do or have access to something on your network.

Accounting

Accounting is a means of keeping track of the entity, while on the network. This is often used by security to track what the entity did, how long they were on the network, what commands they may have entered, etc.

Accounting uses UDP port 1813, prior to IANA allocation 1646

Radius Server

The radius server is sometimes called the AAA server. This is because most common radius servers support all three functions. The Cisco ACS server is an example of such a device.

Other Radius Servers Include:

Juniper Steel Belted Radius

Microsoft IAS (Server 2003)

Microsoft NAP (Server 2008)

Free Radius

Configuration Notes

Speaking from experience (also noted on page 121) there are 2 common mistakes that happen often when setting up a radius server. One is using the wrong port numbers. Two is using the incorrect shared secret between the radius server and the authenticator.  If you have issues in your initial setup, this is something you should check.

RFC

Radius Authentication and Authorization is defined in:

IETF RFC 2865

http://www.ietf.org/rfc/rfc2865.txt

Radius Accounting is defined in:

IETF RFC 2866

http://www.ietf.org/rfc/rfc2866.txt



GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 4 – EAP, EAP, EAP AND MORE EAP, POST#7)- 10/17/2010

Chapter 4 is one of my favorite chapters. Why you ask? It’s the very foundation to advance wireless security.  EAP is the process where it all begins and comes together. 

Have you ever talked to a vendor or colleague who is not familiar with EAP. You get that glazed look, as if you were from another planet? EAP is rather easy to understand once you know the structure. So lets cover the basics first. 

WHAT EAP (IS) AND (IS NOT)

EAP stands for “Extensible Authentication Protocol”. EAP is an authentication frame work that has been around for a long long time.. What EAP is NOT is an authentication mechanism. There is often confusion about this very statement. EAP doesn’t authenticate, but rather it provides the messaging system, the structure, for which authentication mechanisms like EAP-PEAP, EAP-TTLS, EAP-FAST, EAP-LEAP may operate.

EAP was developed long ago, It was used primarily in point to point authentication (PPP). Whereby clients were authenticated to a network using an EAP authentication. Today, EAP is commonly used in wireless authentication and this will be the focus of my notes.

EAP is defined in RF3748 (http://tools.ietf.org/html/rfc3748). As I just shared it is the frame work or the message systems whereby different flavors of EAP can be used.

“Abstract

   This document defines the Extensible Authentication Protocol (EAP),
   an authentication framework which supports multiple authentication
   methods.  EAP typically runs directly over data link layers such as
   Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.  EAP
   provides its own support for duplicate elimination and
   retransmission, but is reliant on lower layer ordering guarantees.
   Fragmentation is not supported within EAP itself; however, individual
   EAP methods may support this.” 

.  Chapter 4 covers a rather broad range of information.

• ·         AAA (Authentication, Authorization, Accounting)
• ·         802.1X Process and structure
• ·         Supplicant Credentials; types and uses
• ·         Authentication Protocols
• ·         EAP

My next few post will be the break down of each section …

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – DEBUGS POST#6)- 10/03/2010

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – debugs#6)- 10/03/2010

If you have gear to play with you can run various commands and see the (802.1X) process at work. I will highlight a few commands quick for brief overview with a Cisco WLC and Cisco autonomous access point. Debug is your friend and I encourage playing with the debug function.

EXAMPLE #1 - Session Timeout

If you are familiar with the Cisco WLCs . You may have noticed a check box called “Enable Session Timeout”. This feature can be found under WLAN-> (pick your wlan)->ADVANCED -> Session Timeout (check box). Session Timeout is feature set per WLAN setting.

This feature allows you to add a reauthenication timer (or shall we say a rekeying event). Lets say for example you keep the 1800 second timeout value. This means every 1800 seconds from the time your client authenticated to the wireless network the WLC will send a deauthentication frame to the client. Thus causing the client to reauthenticate (or shall we say rekey). 

You can also see the clients PMK record in the WLC. Drop into the CLI of the WLC  >show pmk-cache. Under the lifetime value you will see a timer and it counts down. Once it hits zero your client will rekey. This is directly related to the “enable session timeout”

** CAUTION** Some Enterprise environments disable or increase the timeout value to equal 24 hours. Some sensitive applications can be disrupted by frequent re- authentication.

Below is an example:

(Cisco_2006_WLC) >show pmk-cache all

Type        Station         Lifetime   VLAN Override        IP Override

------    --------------    --------   ------------------   ---------------

RSN    00:21:6a:11:a8:02   1775                              0.0.0.0

(Cisco_2006_WLC) >show pmk-cache all

Type        Station         Lifetime   VLAN Override        IP Override

-----    --------------    --------   ------------------   ---------------

RSN    00:21:6a:11:a8:02   1750                              0.0.0.0

Example #2 - Manually Update the GTK on a autonomous access point

Drop into the CLI of the Cisco autonomous access point and issue the following command: 

dot11 dot11Radio 0 update-group-key

ap#dot11 dot11Radio 0 update-group-key

*Mar  2 21:28:05.767: dot11_dot1x_new_key: mcst encrypt mode 0x10 gtk len 32
*Mar  2 21:28:05.767: dot11_dot1x_distribute_bkey: Updating Group Key: vlan=0, index=2, len=32
*Mar  2 21:28:05.767: dot11_dot1x_hex_dump: GTK: 5A CA 2D 68 1C 0E FD A2 DF 6E 8C A4 E6 CE D3 FB 71 F5 6C 84 8C BF EB 35 4C C0 80 CB 3E D1 48 B0
*Mar  2 21:28:05.768: dot11_dot1x_send_ssn_gtk: Sending GTK Message 1 to 0021.6a11.a802
*Mar  2 21:28:05.768: dot11_dot1x_distribute_bkey: Multicast key distributed to 1 clients

Example # 3 - Debug on the Cisco WLC 

There is a host of 802.1x / AAA commands. I deployed dot1x states/event enabled.

(Cisco_2006_WLC) >debug dot1x states enable

(Cisco_2006_WLC) >debug dot1x events enable

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Processing RSN IE type 48, length 20 for mobile d8:30:62:80:61:a1

!! States 0 PMKIDs. This means this is a new device on the WLC and there is no PMKIDs in que

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Received RSN IE with 0 PMKIDs from mobile d8:30:62:80:61:a1

!! The WLC moves the client into the connecting state.

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 dot1x - moving mobile d8:30:62:80:61:a1 into Connecting state

!! The WLC is sending the EAP-Request/Identity

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Sending EAP-Request/Identity to mobile d8:30:62:80:61:a1 (EAP Id 1)

!! The WLC received an EAP packet from the supplicant

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Received EAPOL EAPPKT from mobile d8:30:62:80:61:a1

!! The supplicant responded to the Identity Response

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Received Identity Response (count=1) from mobile d8:30:62:80:61:a1

!! The next state after connecting is authenticating

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 EAP State update from Connecting to Authenticating for mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 dot1x - moving mobile d8:30:62:80:61:a1 into Authenticating state

!! This I understand means the WLC is sending the response to the AAA server

!! “Entering Backend Auth Response state for mobile”

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Entering Backend Auth Response state for mobile d8:30:62:80:61:a1

!! EAP PROCESS

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Processing Access-Challenge for mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Entering Backend Auth Req state (id=112) for mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 WARNING: updated EAP-Identifer 1 ===> 112 for STA d8:30:62:80:61:a1

!! The authentication server (AAA) is sending the EAP request through the WLC

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Sending EAP Request from AAA to mobile d8:30:62:80:61:a1 (EAP Id 112)

!! Response from supplicant

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Received EAPOL EAPPKT from mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Received EAP Response from mobile d8:30:62:80:61:a1 (EAP Id 112, EAP Type 17)

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Entering Backend Auth Response state for mobile d8:30:62:80:61:a1

!! EAP PROCESS

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Processing Access-Challenge for mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Entering Backend Auth Req state (id=112) for mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 WARNING: updated EAP-Identifer 112 ===> 112 for STA d8:30:62:80:61:a1

!! AAA request from server to supplicant

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Sending EAP Request from AAA to mobile d8:30:62:80:61:a1 (EAP Id 112)

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Received EAPOL EAPPKT from mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Received LEAP EAP Request (type=17, ver=1) from mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Entering Backend Auth Response state for mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Processing Access-Accept for mobile d8:30:62:80:61:a1

!! Here is the enable session we talked about. It is set @ 1800 seconds

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Setting re-auth timeout to 1800 seconds, got from WLAN config.

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Station d8:30:62:80:61:a1 setting dot1x reauth timeout = 1800

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Creating a PKC PMKID Cache entry for station d8:30:62:80:61:a1 (RSN 2)

!! Access point adds PMKID cache for supplicant

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Adding BSSID 00:1c:b0:06:d2:d5 to PMKID cache for station d8:30:62:80:61:a1

!! This is the PMK that was derived

Sun Oct  3 11:56:44 2010: New PMKID: (16)

Sun Oct  3 11:56:44 2010:      [0000] 02 4a 48 af f6 d6 32 8f 2b 1f ee cc 5a 0a 58 12

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Disabling re-auth since PMK lifetime can take care of same.

Sun Oct  3 11:56:44 2010: Including PMKID in M1  (16)

Sun Oct  3 11:56:44 2010:      [0000] 02 4a 48 af f6 d6 32 8f 2b 1f ee cc 5a 0a 58 12

!! Message 1 – This is our first exchange in the 4 way handshake. This is where the authenticator sends the ANonce and mac address.

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Sending EAPOL-Key Message to mobile d8:30:62:80:61:a1

 state INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Entering Backend Auth Success state (id=112) for mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 Received Auth Success while in Authenticating state for mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:44 2010: d8:30:62:80:61:a1 dot1x - moving mobile d8:30:62:80:61:a1 into Authenticated state

Sun Oct  3 11:56:45 2010: d8:30:62:80:61:a1 802.1x 'timeoutEvt' Timer expired for station d8:30:62:80:61:a1

!! Message received from the supplicant

Sun Oct  3 11:56:45 2010: d8:30:62:80:61:a1 Received EAPOL-Key from mobile d8:30:62:80:61:a1

!! Message 2 – This is our second exchange in the 4 way handshake. This client is send the SNonce and the supplicant mac address.

Sun Oct  3 11:56:45 2010: d8:30:62:80:61:a1 Received EAPOL-key in PKT_START state (message 2) from mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:45 2010: d8:30:62:80:61:a1 Stopping retransmission timer for mobile d8:30:62:80:61:a1

!! Message 3 – This is our third exchange in the 4 way handshake. This is where the GTK is being derived and sent back at the supplicant.

Sun Oct  3 11:56:45 2010: d8:30:62:80:61:a1 Sending EAPOL-Key Message to mobile d8:30:62:80:61:a1

state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.02

Sun Oct  3 11:56:45 2010: d8:30:62:80:61:a1 Received EAPOL-Key from mobile d8:30:62:80:61:a1

!! Message 4 – This is our fourth exchange in the 4 way handshake. This is confirmation the keys were installed.

Sun Oct  3 11:56:45 2010: d8:30:62:80:61:a1 Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile d8:30:62:80:61:a1

Sun Oct  3 11:56:45 2010: d8:30:62:80:61:a1 Stopping retransmission timer for mobile d8:30:62:80:61:a1

Sun Oct  3 11:57:40 2010: d8:30:62:80:61:a1 Sending EAPOL-Key Message to mobile d8:30:62:80:61:a1

state PTKINITDONE (message 5 - group), replay counter 00.00.00.00.00.00.00.03

!! Message 5 – Is our group key update

!! You can see here it states updated broadcast key and it was sent to the supplicant

Sun Oct  3 11:57:40 2010: d8:30:62:80:61:a1 Updated broadcast key sent to mobile D8:30:62:80:61:A1

!! Group key timer is set @ 3653 seconds. At which point the group key will be re-keyed.

Sun Oct  3 11:57:40 2010: 00:1c:b0:06:d2:d0 Resetting the group key timer for 3653 seconds on AP 00:1c:b0:06:d2:d0(0)

Sun Oct  3 11:57:40 2010: d8:30:62:80:61:a1 Received EAPOL-Key from mobile d8:30:62:80:61:a1

!! Message 6 – This is confirmation the from the supplicant

Sun Oct  3 11:57:40 2010: d8:30:62:80:61:a1 Received EAPOL-key in REKEYNEGOTIATING state (message 6) from mobile d8:30:62:80:61:a1

Sun Oct  3 11:57:40 2010: d8:30:62:80:61:a1 Stopping retransmission timer for mobile d8:30:62:80:61:a1

Play with the debugs ... ENJOY!

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – 4- WAY HANDSHAKE POST#5)- 10/03/2010

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – 4 WAY HANDSHAKE POST#5)- 10/03/2010

The 4-way handshake is a unique process and thus why I think it is important to cover in detail. But first lets recap.

We’ve learned  the MSK (Master Session Key)  is used for seeding material in the creation of the PMK (Pairwise Master Key) . The PMK (Pairwise Master Key) and GMK (Group Master Key)  are then seeding material for the PTK (Pairwise Transient Key) and GTK (Group Temporal Key).

The MSK and PMK are negotiated between the supplicant and the authentication server (AAA). Once created, these keys are then moved to the authenticator (access point) via a Radius packet.

In contrast, PTK (Pairwise Transient Key) is derived differently. It is derived between the supplicant and the authenticator (access point). The authentication server (AAA), at this stage, has completed it’s task and is out of the mix.

Since the supplicant and the authenticator have mutual information about each other (PMK) key . They both can derive their unique Temporal keys in a process called the “4-way handshake” .

The purpose of the 4-way handshake is to derive a unique PTK key that will be used to encrypt client unicast traffic between this station and the access point.  This key is unique. No two stations on an access point will have identical PTK keys.

So lets get started …

After a successful EAP authentication the 4-way handshake begins. Note, as I mentioned before, this is now between the supplicant and the authenticator. 

The 4-way handshake shares very unique and random information between the supplicant and the access point to derive the PTK key. There is something called PRF (pseudo-random function). It uses a combination of “randomness”, as I like to call it.

It includes the PMK+ Supplicant Mac Address + Authenticator Mac Address + random Nonces) Here is the formula, it can be found on page 199 of the CWSP.

It’s a great visual …

PTK = PRF (PMK + ANonce + SNonce + AA + SPA )

Here are the definitions for reference:

PRF (pseudo-random function) -  A collection of efficiently-computable functions which emulate a random oracle in the following way: no efficient algorithm can distinguish (with significant advantage) between a function chosen randomly from the PRF family and a random oracle (a function whose outputs are fixed completely at random). Pseudorandom functions are vital tools in the construction of cryptographic primitives, especially secure encryption schemes.

Nonce - is an abbreviation of number used once (it is similar in spirit to a nonce word). It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.

ANonce – A authenticator nonce

SNonce – A supplicant nonce

AA – Authenticators Mac Address (access point)

SPA – Supplicants Mac Address (wireless client)

The 4-way handshake looks like a simple 4-way frame exchange. But inside these frames “random” magic is happening before your very eyes. Below is a breakdown of each exchange:

4-way handshake message 1

In the first message, the authenticator sends the supplicant a nonce. This is referred to as the ANonce. Along with this ANonce, the frame includes the authenticators mac address. At this point the supplicant has all the goods to create the PTK. It has the Anonce, authenticators mac address as well as its own Snonce and mac address, of itself.

4-way handshake message 2

The supplicant creates its nonce. This is referred to as the SNonce. The supplicant can now calculate the PTK because it has all the goods from the first handshake. In the second message, the supplicant sends the SNonce to the authenticator. The supplicant also sends the security parameters (RSN) information. The entire message gets an authentication check using the (KCK/MIC) from the pairwise key hierarchy. The authenticator can then verify that the information, including the security parameters sent at association are valid.

4-way handshake message 3 

In the third message the authenticator derives the GTK key from the GMK key. The authenticator derives an ANonce, RSN information element info and a MIC. This information is then sent to the supplicant in a EAPOL-Key frame. This is kept  secret  from sniffing, because it is encrypted within the PTK.  

4-way handshake message 4 

The fourth message acts as a confirmation. It indicates that the temporal keys are installed.

The PTK is comprised into three keys which is important to know, I like to call them the “internal PTK” keys. These KCK, KEK, and TK component. These keys secure the 4-way handshake (KCK), provide data integrity during the 4-way handshake (KCK) and provide encryption used to encrypt and decrypt the MSDU payload of 802.11 data frames between the station and the access point.  

Key Confirmation Key (KCK) - The first key is the EAPOL-key confirmation key (KCK). The KCK is used by the EAPOL-key exchanges to provided data origin authenticity.

Key Encryption Key (KEK) - The second key is the EAPOL-key encryption key (KEK). The KEK is used by the EAPOL-key exchanges to provide for confidentiality.

Temporal Key (TK) - The third key is the temporal key, which is used by the data-confidentiality protocols (TKIP/CCMP)

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – KEYS POST#4)- 9/10/2010

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 5 – KEYS POST#4)- 9/10/2010

First, this is a lot of information and it is very detailed at that. I encourage further reading and study for a complete step by step explanation. These are my notes for reference. I hope you find them useful. 

If you are new to wireless security especially 802.11i, one could be intimidated by all of these KEYS. I can remember thinking to myself, “Why in gods name is there so many keys and they do what again!?”

I would encourage you to read Chapter 5 of the official CWSP study guide, Devin’s ‘chicken egg’ white  paper and the 802.11 Wireless Networks ‘Definitive Guide 2^nd edition’ for a full explanation.

To simplify, I would like to reference fig 5.18 on page 194 of the CWSP study guide. The pyramid offers a great visual as to the RSN Key Hierarchy process.  Let’s break down each LAYER.

“Master Session Key - MSK”

The MSK is sometimes called the ‘AAA key’. The MSK is on top of the food chain and will provide “seeding  / keying material” for the PMK (Pairwise Master Key). MSKs are created during the 802.1X/EAP process.

802.1X/EAP –  The MSK is derived at the supplicant and the authentication server (AAA) during the EAP authentication process. The supplicant and the authentication server (AAA) will know information about each other during the “mutual” authentication exchange of credentials. I added a GREAT Peap Choreography at the end of this post.

(this is all black magic and is outside of the scope of the exam)

What is important to remember is that both the supplicant and authentication server (AAA) have both derived identical  MSK keys during this mutual authentication process which will later be used as seeding material for PMKs.

PSK -  In the case where PSK is used, whereby putting a static PSK key on a station and access point  there is no MSK keying material because there is no authentication server (AAA) in use to derive a MSK. So your PSK is your PMK.

Additional reading material

<RFC4017 states>
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP
method. The MSK is at least 64 octets in length. In existing implementations, an AAA server acting as an EAP server 

transports the MSK to the authenticator.
<802.11 2007 states:> 
 3.80 master session key (MSK): Keying material that is derived between the Extensible Authentication Protocol (EAP) peer  and
 exported by the EAP method to the Authentication Server (AS). This key is at least 64 octets in length.

“Master Key Layer”

Next layer down on the food chain is the “Master Key Layer”. This is where your PMK (Pairwise Master Key) and GMK (Group Master Key) will be derived! 

PMK  (Pairwise Master Key)

The purpose of the PMK is to create seeding material for the PTK (pairewise transient key)

The PMK is derived by the station and authentication server (AAA). The PMK shall be computed as the first 256 bits (bits 0–255) of the MSK. Since the station and the authentication server (AAA) both have the same MSK, because of the 802.1X/EAP process, the PMKs derived will be identical.

The PMK that is derived at the authentication server (AAA) is sent to the authenticator. Once this occurs the station and authenticator  both have identical PMKs. The PMK is unique between the station and the authenticator. No other station will have identical PMKs. A new PMK is generated when a station authenticates or re-authenticates . PMKs are also used in ‘fast’ roaming, whereby a client can negate a full 802.1X authentication. More about that in a future blog post. Again, keep in mind that the PMK is used as seeding material to create the PTK. 

PSK -   In the case where you use a PSK (PreShare Key)  on a station and access point the Master Keys are derived by using a passphrase-to-PSK mapping.   So your PSK is your PMK key. 

Additional reading material

< IEEE Std 802.11 - 2007>
3.97 pairwise master key (PMK): The highest order key used within this standard. The PMK may be derived from a key generated by an Extensible Authentication Protocol (EAP) method or may be obtained directly from a preshared key (PSK).

< IEEE Std 802.11 - 2007>
The PTK shall not be used longer than the PMK lifetime as determined by the minimum of the PMK lifetime indicated by the AS, e.g., Session-Timeout + dot1xAuthTxPeriod or from the
dot11RSNAConfigPMKLifetime MIB variable. When RADIUS is used and the Session-Timeout attribute is not in the RADIUS Accept message, and if the key lifetime is not otherwise specified, then the PMK lifetime is infinite.

< IEEE Std 802.11 - 2007>
When not using a PSK, the PMK is derived from the MSK. The PMK shall be computed as the first 256 bits (bits 0–255) of the MSK: PMK L(MSK, 0, 256). When this derivation is used, the MSK must consist of at least 256 bits

< IEEE Std 802.11 - 2007> 5.8.2.2 Operations with PSK

The following AKM operations are carried out when the PMK is a PSK:
— A STA discovers the AP’s security policy through passively monitoring Beacon frames or through active probing (shown in Figure 5-11). A STA associates with an AP and negotiates a security
policy. The PMK is the PSK.

— The 4-Way Handshake using EAPOL-Key frames is used, just as with IEEE 802.1X authentication,
when an AS is present. See Figure 5-13.

— The GTK and GTK sequence number are sent from the Authenticator to the Supplicant just as in the
AS case. See Figure 5-13 and Figure 5-14.

GMK  (Group Master Key)

The GMK is randomly created by the authenticator. The purpose of the GMK is to create “seeding material” for the GTK. The GMK lives on the authenticator ONLY. Each authenticator will have it’s own unique GMK. Some vendors allow you to change the GMK dynamically.  I will share more on this in a future blog post.

“Temporal Key Layer”

In the temporal key layer we will discuss two keys. The PTK (Pairwise Transient Key) and  GTK (Group Temporal Key). Both have very unique tasks …. The temporal keys are derived via the 4-Way Handshake process.

PTK (Pairwise Transient Key)

The propose of the PTK keys is to encrypt unicast traffic between the station and access point. The PTK is a unique encryption key and no other station will have the same identical PTK key.

The PTK is composed of 3 parts"

Key Confirmation Key (KCK), Key Encryption Key (KEK), Temporal Key (TK)

GTK  (Group Temporal Key)

The purpose of the GTK key is to encrypt broadcast and multicast traffic between the client(s) and access point (BSS). ALL THE CLIENTS on the same BSS will share identical GTK keys.  That right, multicast and broadcast traffic are keyed separate from the unicast traffic. Keeping in mind this is WHY when using a transitional network, your lowest encryption type is used for your GTK key.

You may have heard about the recent buzz in the industry around “hole 196”. This was based on the exploitation of the GTK key. 

An important part of the PTK and GTK is the 4-way handshake. My next post will cover this in detail ..

 Great image of the frame exchange process